Within a system based on a service-oriented architecture, new services are often created by combining existing services together in a new way. Depending on the exact method of service combination, this technique might be known as orchestration, choreography or “mashing-up”. Orchestration usually involves some central control mechanism that invokes or otherwise involves numerous underlying services to provide an overall, composite result or desired outcome. Such orchestration allows new solutions or services to be assembled or compiled relatively quickly by redistributing and/or combining a palette of existing, underlying services.
For example, consider a service or application for assembling resources in response to a particular event, e.g., assembling personnel to respond to an emergency, compiling equipment needed for a task, etc. An initial action triggers or otherwise invokes the orchestrated resource assembly service. This, in turn, actuates underlying location, database, messaging, mapping, logging and/or other additional services to identify and select available resources, provide instructions, log the actions taken for audit purposes, etc.
The particular application or service may be invoked infrequently (perhaps once a day, perhaps once a year) and, as with any infrequently-utilized system, the issue arises as to whether the system or service is able to successfully deliver the desired result, e.g., are the required resources available, are the items needed operational, etc. In other words, there is an ever-present risk that an idle or typically offline resource has failed silently during the period of non-use and/or is otherwise simply unavailable. The condition of an undetected failure or lack of availability can have disastrous consequences depending on the particular nature and environment in which the orchestration system is being utilized. In a business setting, for example, unavailable resources may lead to a loss of profit or productivity, while in a healthcare setting, if an emergency occurs and the needed resources are unavailable, the result could be a loss of life.
To reduce the likelihood of failure or unavailability, systems or events may be routinely enacted or tested through a “fire drill,” or the like, where the actual service or resources are enacted to perform their duties under a simulated assumption that a triggering event has occurred. However, even though the actual event or condition to which the systems, applications, or resources must respond has not actually occurred, the resources are nonetheless then occupied with performing their assumed duties during the drill, which prevents them from completing actual tasks or responding to actual events. In other words, while a practice drill may ensure operational capacity or availability of certain resources, during such a practice drill these resources are unable to complete other tasks, which increases inefficiency as well as loss of productivity.
In view of the above, it is desirable to have a system and method to gauge or otherwise simulate an orchestrated service or procedure to determine the availability of resources, thereby allowing for strategic changes in scheduling, purchasing, hiring, and the like to ensure that the resources needed to deliver the desired outcome during a particular time period are indeed present, without occupying the actual resources to do so.